Continuous Multi-Factor Authentication

ABSTRACT

Technologies for continuously authenticating a user via multiple authentication factors include a computing device for generating a continuous authentication assertion indicating that continuous authentication of a user is being monitored, sending the continuous authentication assertion to a key distribution center server, and requesting and receiving an initial ticket from the key distribution center server. Such technologies may also include requesting a service ticket from the key distribution center server for accessing a service provider server, receiving a service ticket from the key distribution center server including the continuous authentication assertion, requesting access to the service provider server with the service ticket including the continuous authentication assertion, and accessing the service provider server in response to the continuous authentication assertion being verified.

This application is a continuation of U.S. patent application Ser. No.14/129,443, filed Dec. 26, 2013, which is a §371 national stage ofinternational application PCT/US2013/048220, which filed Jun. 27, 2013,the content of which is hereby incorporated by reference.

BACKGROUND

Multi-factor authentication is an approach to computerized securityprocedures that requires the user to provide more than one form ofverification to prove their identity in order to gain access tosensitive data or computer systems. Commonly-used forms of verificationinclude knowledge-based verification data (e.g., something the userknows, such as a password or Personal Identification Number),token-based verification data (e.g., something the user has, such as aprivate key, security token or smart card), and biometric data (e.g., aphysiological or behavioral characteristic of the user). More recently,efforts have been undertaken to continuously authenticate the user toincrease the security of sensitive data or computer systems.

Existing network security infrastructures typically utilize one or morenetwork authentication protocols such as, for example, Kerberos toauthenticate users and control which network resources users arepermitted to access. To do so, many of these network securityinfrastructures include one or more authentication components, which areoften well-established systems within the network infrastructure. Suchauthentication systems, however, do not support continuous userauthentication. Further, modifying existing authentication systems toinclude additional functionally can be costly and error prone.

BRIEF DESCRIPTION OF THE DRAWINGS

The concepts described herein are illustrated by way of example and notby way of limitation in the accompanying figures. For simplicity andclarity of illustration, elements illustrated in the figures are notnecessarily drawn to scale. Where considered appropriate, referencelabels have been repeated among the figures to indicate corresponding oranalogous elements.

FIG. 1 is a simplified block diagram of at least one embodiment of asystem for using a computing device to provide continuous multi-factorauthentication;

FIG. 2 is a simplified block diagram of at least one embodiment of anenvironment of the client computing device of the system of FIG. 1;

FIG. 3 is a simplified block diagram of at least one embodiment of anenvironment of the service provider server of the system of FIG. 1;

FIG. 4 is a simplified flow diagram of at least one embodiment of amethod that may be executed by the computing device of FIGS. 1 and 2 forcontinuously authenticating a user via multiple authentication factors;

FIG. 5 is a simplified flow diagram of at least one embodiment of amethod that may be executed by the computing device of FIGS. 1 and 2 formonitoring continuous user authentication;

FIG. 6 is a simplified activity flow diagram of at least one embodimentof the methods of FIGS. 4 and 5 for continuously authenticating a uservia multiple authentication factors;

FIG. 7 is a simplified activity flow diagram of another embodiment ofthe methods of FIGS. 4 and 5 for continuously authenticating a user viamultiple authentication factors;

FIG. 8 is a simplified activity flow diagram of another embodiment ofthe methods of FIGS. 4 and 5 for continuously authenticating a user viamultiple authentication factors; and

FIG. 9 is a simplified activity flow diagram of another embodiment ofthe methods of FIGS. 4 and 5 for continuously authenticating a user viamultiple authentication factors.

DETAILED DESCRIPTION

While the concepts of the present disclosure are susceptible to variousmodifications and alternative forms, specific embodiments thereof havebeen shown by way of example in the drawings and will be describedherein in detail. It should be understood, however, that there is nointent to limit the concepts of the present disclosure to the particularforms disclosed, but on the contrary, the intention is to cover allmodifications, equivalents, and alternatives consistent with the presentdisclosure and the appended claims.

References in the specification to “one embodiment,” “an embodiment,”“an illustrative embodiment,” etc., indicate that the embodimentdescribed may include a particular feature, structure, orcharacteristic, but every embodiment may or may not necessarily includethat particular feature, structure, or characteristic. Moreover, suchphrases are not necessarily referring to the same embodiment. Further,when a particular feature, structure, or characteristic is described inconnection with an embodiment, it is submitted that it is within theknowledge of one skilled in the art to effect such feature, structure,or characteristic in connection with other embodiments whether or notexplicitly described.

The disclosed embodiments may be implemented, in some cases, inhardware, firmware, software, or any combination thereof. The disclosedembodiments may also be implemented as instructions carried by or storedon a transitory or non-transitory machine-readable (e.g.,computer-readable) storage medium, which may be read and executed by oneor more processors. A machine-readable storage medium may be embodied asany storage device, mechanism, or other physical structure for storingor transmitting information in a form readable by a machine (e.g., avolatile or non-volatile memory, a media disc, or other media device).

In the drawings, some structural or method features may be shown inspecific arrangements and/or orderings. However, it should beappreciated that such specific arrangements and/or orderings may not berequired. Rather, in some embodiments, such features may be arranged ina different manner and/or order than shown in the illustrative figures.Additionally, the inclusion of a structural or method feature in aparticular figure is not meant to imply that such feature is required inall embodiments and, in some embodiments, may not be included or may becombined with other features.

Referring now to FIG. 1, in an illustrative embodiment, a system 100 forcontinuously authenticating a user 102 via multiple authenticationfactors includes a client computing device 110, a key distributioncenter server 130, and a service provider server 140. In use, the clientcomputing device 110 is configured to authenticate the user 102 usingmultiple authentication factors (e.g., biometric, proximity, user input,user presence, etc.) and monitor the continuous authentication of theuser 102 of the client computing device 110. The client computing device110 is also configured provide an assertion that the authentication ofthe user 102 is being continuously monitored. In some embodiments, theclient computing device 110 provides the assertion of continuous userauthentication monitoring to the key distribution center server 130,which may be configured to issue one or more service tickets and/orcredentials necessary to access the service provider server 140 or aparticular resource provided by the service provider server 140. Theservice tickets provided by the key distribution center server 130 mayinclude the assertion of continuous user authentication monitoringwhich, as discussed in more detail below, may be verified by the serviceprovider server 140 prior to granting access to the client computingdevice 110. In this way, the client computing device 110 rather than thekey distribution center server 130 may perform continuous authenticationof the user 102 and, as a result, the need for modifying and/orre-deploying the key distribution center server 130 may be reduced.

The client computing device 110 may be embodied as any type of computingdevice capable of performing the functions described herein including,but not limited to, a desktop computer, a set-top box, a smart displaydevice, a server, a mobile phone, a smart phone, a tablet computingdevice, a personal digital assistant, a consumer electronic device, alaptop computer, a smart display device, a smart television, and/or anyother type of computing device. As shown in FIG. 1, the illustrativeclient computing device 110 includes a processor 112, a memory 114, aninput/output (I/O) subsystem 116, a data storage 120, communicationcircuitry 124, and one or more sensors 126. Of course, the clientcomputing device 110 may include other or additional components, such asthose commonly found in a computer and/or a server (e.g., variousinput/output devices), in other embodiments. Additionally, in someembodiments, one or more of the illustrative components may beincorporated in, or otherwise from a portion of, another component. Forexample, the memory 114, or portions thereof, may be incorporated in theprocessor 112 in some embodiments.

The processor 112 may be embodied as any type of processor capable ofperforming the functions described herein. For example, the processor112 may be embodied as a single or multi-core processor(s), digitalsignal processor, microcontroller, or other processor orprocessing/controlling circuit. Similarly, the memory 114 may beembodied as any type of volatile or non-volatile memory or data storagecapable of performing the functions described herein. In operation, thememory 114 may store various data and software used during operation ofthe client computing device 110 such as operating systems, applications,programs, libraries, and drivers. The memory 114 is communicativelycoupled to the processor 112 via the I/O subsystem 116, which may beembodied as circuitry and/or components to facilitate input/outputoperations with the processor 112, the memory 114, and other componentsof the client computing device 110. For example, the I/O subsystem 116may be embodied as, or otherwise include, memory controller hubs,input/output control hubs, firmware devices, communication links (i.e.,point-to-point links, bus links, wires, cables, light guides, printedcircuit board traces, etc.) and/or other components and subsystems tofacilitate the input/output operations. In some embodiments, the I/Osubsystem 116 may form a portion of a system-on-a-chip (SoC) and beincorporated, along with the processor 112, the memory 114, and othercomponents of the client computing device 110, on a single integratedcircuit chip.

In some embodiments, the I/O subsystem 116 may include a trustedexecution environment module 118, which may be embodied as an embeddedmicroprocessor, such as a security co-processor, that operatesindependently of the processor 112 to provide a secure and isolatedenvironment that cannot be accessed by the processor 112 or othercomponents of the client computing device 110. In such embodiments, thetrusted execution environment module 118 may manage the storage of oneor more encryption keys used by the client computing device 110 tosecure data and/or communications between the client computing device110 and one or more of the key distribution center server 130 and theservice provider server 140. In such embodiments, the one or moreencryption keys may be stored in a portion of the memory 114 that isaccessible to the trusted execution environment module 118 andinaccessible to other components of the client computing device 110. Inother embodiments, the trusted execution environment module 118 mayinclude internal or local secured memory, separate from the memory 114,in which the encryption keys may be stored. It should be appreciatedthat the trusted execution environment module 118 may also securelystore other types of data in the portion of memory 114 that isaccessible to the trusted execution environment module 118 andinaccessible to other components of the client computing device 110.Additionally, the trusted execution environment module 118 may, in someembodiments, function in an operational power state while the processor112 and other components of the client computing device 110 are in alow-power state (e.g., sleep, hibernate, etc.) or are powered-down. Asdiscussed in more detail below, in some embodiments, the trustedexecution environment module 118 may also generate a public/private keypair on behalf of the client computing device 110 and/or the user 102 tofacilitate the receipt of one or more service tickets and/or credentialsfrom the key distribution center server 130. It should be appreciatedthat in some embodiments, however, other components of the clientcomputing device 110 may instead generate the public/private key pair onbehalf of the client computing device 110 and/or the user 102. Further,as discussed in more detail below, the trusted execution environmentmodule 118 may also monitor for the continuous authentication of theuser 102 of the client computing device 110 and assert to the keydistribution center server 130 that such monitoring is being performed.

Additionally, it should be appreciated that in embodiments wherein theclient computing device 110 includes a trusted execution environmentmodule 118, the trusted execution environment module 118, or any of thefunctionality thereof, may be implemented using Intel® Active ManagementTechnology (AMT), using a portion of Intel® AMT, using an Intel®Management Engine (ME), using Intel® vPro™ Technology, using Intel®Core™ vPro™ Technology, using Intel® Identity Protection Technology(IPT), and/or using Intel® IPT with Public Key Infrastructure (PKI),each of which are available from Intel Corporation of Santa Clara,Calif., and/or within chipsets available from Intel Corporation. Itshould be appreciated, however, that the trusted execution environmentmodule 118, or any of the functionality thereof, may be implementedusing other components and/or technologies of trusted computing devicesavailable from other manufacturers.

The communication circuitry 124 of the client computing device 110 maybe embodied as any type of communication circuit, device, or collectionthereof, capable of enabling communications between the client computingdevice 110, the key distribution center server 130, the service providerserver 140, and/or other computing devices. The communication circuitry124 may be configured to use any one or more communication technologies(e.g., wireless or wired communications) and associated protocols (e.g.,Ethernet, WiMAX, etc.) to effect such communication. In someembodiments, the client computing device 110 and the key distributioncenter server 130 and/or the service provider server 140 may communicatewith each other over a network 180.

The network 180 may be embodied as any number of various wired and/orwireless communication networks. For example, the network 180 may beembodied as or otherwise include a local area network (LAN), a wide areanetwork (WAN), a cellular network, or a publicly-accessible, globalnetwork such as the Internet. Additionally, the network 180 may includeany number of additional devices to facilitate communication between theclient computing device 110, the key distribution center server 130, theservice provider server 140, and/or the other computing devices.

The data storage 120 may be embodied as any type of device or devicesconfigured for short-term or long-term storage of data such as, forexample, memory devices and circuits, memory cards, hard disk drives,solid-state drives, or other data storage devices. In some embodiments,the client computing device 110 may store various types of data and/orsoftware that the processor 112 is not expected to process in the nearfuture and/or is desirable to retain for extended periods of time.

The one or more sensors 126 may be embodied as any type of device ordevices configured to sense characteristics of the user 102 and/or theproximity of the user 102 relative to the client computing device 110.For example, in some embodiments, the one or more sensors 126 may beembodied as, or otherwise include, one or more biometric sensorsconfigured to sense physical attributes (e.g., facial features, speechpatterns, retinal patterns, fingerprints, etc.) and/or behavioralcharacteristics (e.g., eye movement, visual focus, body movement, keyinput force, key input speed, etc.) of the user 102. Additionally oralternatively, the one or more sensors 126 may be embodied as, orotherwise include, one or more proximity detection sensors configured tosense the proximity of the user 102 or a physical token (e.g., aradio-frequency identification tag, a near field communication tag, aradio frequency transmitter, etc.) carried by the user 102. The one ormore sensors 126 may also be embodied as one or more sensors configuredto sense the user's 102 interaction with the client computing device110. For example, in some embodiments, the one or more sensors 126 maybe embodied as one or more accelerometers configured to sense thecarrying and/or movement of the client computing device 110 by the user102. It should be appreciated that although the client computing device110 includes the one or more sensors 126 in the illustrative embodiment,it should be understood that all or a portion of the one or more of thesensors 126 may be separate from the client computing device 110 inother embodiments. As discussed below, the information sensed by the oneor more sensors 126 may be used in part to authenticate the user 102 tothe client computing device 110.

The key distribution center server 130 may be embodied as any type ofserver capable of performing the functions described herein. As such,the key distribution center server 130 may include various hardware andsoftware components (e.g., a processor, memory, and communicationcircuitry) typically found in a server for communicating, storing,maintaining, and transferring data over the network 180. In operation,the key distribution center server 130 may be configured to generate oneor more service tickets and/or credentials for accessing the serviceprovider server 140 and/or a resource of the service provider server140. To do so, the key distribution center server 130 may be configuredto communicate with the trusted execution environment module 118 overthe network 180, which is acting on behalf of the user 102. In someembodiments, the key distribution center server 130 may establish atrust with the trusted execution environment module 118 via one or morekey exchanges (e.g., SIGn-and-MAc (SIGMA), Diffie-Hellman, PKINIT,etc.). It should be appreciated that, in some embodiments, the keydistribution center server 130 may have previously established a trustwith the trusted execution environment module 118 via one or more keyexchanges (e.g., SIGn-and-MAc (SIGMA), Diffie-Hellman, PKINIT, etc.). Ineither case, the key distribution center server 130 may receive anassertion from the trusted execution environment module 118 that thecontinuous authentication of the user 102 is being monitored. Asdiscussed in more detail below, the key distribution center server 130may also be configured to include the assertion in the one or moreservice tickets and/or credentials provided to the client computingdevice 110 for accessing the service provider server 140 and/or aresource of the service provider server 140.

The service provider server 140 may be embodied as any type of servercapable of performing the functions described herein. As such, theservice provider server 140 may include various hardware and softwarecomponents (e.g., a processor, memory, and communication circuitry)typically found in a server for communicating, storing, maintaining, andtransferring data over the network 180. The service provider server 140is configured to provide one or more resources (e.g., file access,network services, etc.) to the client computing device 110. In someembodiments, the service provider server 140 is configured to enable theclient computing device 110 to access such resources in response toverifying the assertion from the client computing device 110 that theauthentication of the user 102 is being continuously monitored. Asdiscussed in more detail below, the assertion from the client computingdevice 110 may be included within the service ticket originally providedby the key distribution center server 130.

Referring now to FIG. 2, in use, the client computing device 110establishes an environment 200 during operation. The illustrativeenvironment 200 includes a communication module 202, the trustedexecution environment module 118, and the one or more sensors 126. Eachof the modules 202, 118, 126 of the environment 200 may be embodied ashardware, software, firmware, or a combination thereof. It should beappreciated that the client computing device 110 may include othercomponents, sub-components, modules, and devices commonly found in acomputing device, which are not illustrated in FIG. 2 for clarity of thedescription.

The communication module 202 of the client computing device 110facilitates communications between components or sub-components of theclient computing device 110 and the key distribution center server 130and/or the service provider server 140. For example, the communicationmodule 202 may facilitate sending and receiving communication messages(e.g., public/private key pairs, digital certificates, user presenceinformation, authentication information, credentials, access tickets,access requirements, etc.) to and from the key distribution centerserver 130 and/or the service provider server 140. Additionally, in someembodiments, the communication module 202 manages communications betweencomponents or sub-components of the client computing device 110. Forexample, the communication module 202 may facilitate communicationsbetween the trusted execution environment module 118 and the one or moresensors 126 and/or other components of the client computing device 110.

The trusted execution environment module 118 manages user authenticationand the credentials needed for the user 102 to access, via the clientcomputing device 110, the service provider server 140 and/or one or moreresources provided by the service provider server 140. As discussedbelow, the trusted execution environment module 118 also continuouslymonitors the user's 102 presence relative to the client computing device110. To do so, in some embodiments, the trusted execution environmentmodule 118 may include a presence monitoring module 204, a userauthentication module 206, and a credential management module 208.

The presence monitoring module 204 of the trusted execution environmentmodule 118 may continuously monitor the user's 102 presence with respectto the client computing device. That is, the presence monitoring module204 may determine whether the user 102 is located in proximity to theclient computing device 110. To do so, the presence monitoring module204 may receive information sensed by one or more of the sensors 126indicative of the proximity of the user 102 relative to the clientcomputing device 110. For example, the one or more sensors 126 may beconfigured to sense one or more user inputs (e.g., keyboard input,touchpad input, touch screen input, etc.), wireless communications(e.g., near field communications, radio frequency identificationcommunications, Bluetooth® communications, Wi-Fi® communications, etc.),and/or device component outputs (e.g., accelerometer data, ambient lightsensor data, digital camera images, etc.). In response to receiving anysuch information from the one or more sensors 126, the presencemonitoring module 204 may determine whether the user 102 is locatedwithin a reference distance from the location of the client computingdevice 110. Additionally or alternatively, the presence monitoringmodule 204 may also be configured to determine whether the user 102 isno longer located within the reference distance from the location of theclient computing device 110. In some embodiments, the presencemonitoring module 204 is configured to generate user presence dataindicative of whether the user 102 is located within the referencedistance of the location of the client computing device 110.

The user authentication module 206 of the trusted execution environmentmodule 118 may facilitate authenticating the user 102 to the clientcomputing device 110. To do so, the user 102 may be requested to provideverification data to prove their identity to the client computing device110. The verification data may include knowledge-based verification data(e.g., something the user knows, such as a password or PersonalIdentification Number), token-based verification data (e.g., somethingthe user has, such as a private key, security token or smart card),and/or biometric verification data (e.g., a physiological or behavioralcharacteristic of the user). In some embodiments, the userauthentication module 206 may require the user 102 to provide a singleform of verification data in order to prove their identity. However, inother embodiments, the user authentication module 206 may insteadrequire the user 102 to provide multiple authentication factors (e.g.,multiple forms of verification data) to the client computing device 110in order to prove their identity. The verification data may be providedby the user 102 via one or more user inputs (e.g., via a keyboard,touchpad, touch screen, wireless communication devices, etc.).Additionally or alternatively, the verification data may include datareceived from the one or more sensors 126 and/or the presence monitoringmodule 204. For example, in some embodiments, the verification data mayinclude biometric verification data received from the one or moresensors 126. Additionally, the verification data may include the userpresence data received from the presence monitoring module 204.Regardless, the user authentication module 206 is configured toauthenticate the user 102 based at least in part on, or otherwise as afunction of, the one or more forms of verification data.

In some embodiments, the user authentication module 206 may require theuser 102 to provide the one or more forms of verification data duringinitialization (e.g., initial boot) of the client computing device 110.It should be appreciated that the user authentication module 206 mayalso require the user to provide the one or more forms of verificationdata at any other time during operation of the client computing device110. For example, in some embodiments, the user authentication module206 may require the user 102 to continuously authenticate to the clientcomputing device 110. That is, the user 102 may be required to provetheir identity to the client computing device 110 according to areference time interval (e.g., every five minutes, every ten minutes,every fifteen minutes, etc.). Additionally, in some embodiments, theuser 102 may be required be continuously present at the client computingdevice 110 after initially proving their identity using one or moreother forms of verification data.

The credential management module 208 of the trusted executionenvironment module 118 may facilitate obtaining the credentialsnecessary for enabling the user 102, via the client computing device110, to access the service provider server 140 and/or one or moreresources provided by the service provider server 140. For example, insome embodiments, a Kerberos network security protocol is used to manageaccess to the service provider server 140. In such embodiments, thecredential management module 208 may be configured to obtain a serviceticket required for accessing the service provider server 140 from thekey distribution center server 130. To do so, the credential managementmodule 208 may exchange public/private key pairs with the keydistribution center server 130, request and receive a ticket grantingticket from the key distribution center server 130, and request andreceive a service ticket for accessing the service provider server 140from the key distribution center server 130.

As discussed, continuous user authentication may be required by the userauthentication module 206. For example, in some embodiments, the user102 may be required be continuously authenticated by the clientcomputing device 110 after initial authentication via one or more formsof verification data. In such embodiments, the credential managementmodule 208 may be configured to generate and provide an assertion to thekey distribution center server 130 that the user's 102 authentication isbeing continuously monitored by the client computing device 110. Theassertion may be provided (e.g., transmitted, sent, etc.) to the keydistribution center server 130 over the network 180. Additionally oralternatively, in some embodiments, the assertion may includeinformation indicative of the factors (e.g., the forms of verificationdata) used to authenticate the user 102. For example, in someembodiments, the assertion may include information indicating that theuser 102 was authenticated via a username and password received from akeyboard in combination with user presence data sensed by the one ormore sensors 126. Additionally, in some embodiments, the assertion maybe embodied as a security assertion markup language (SAML) message or aKerberos safe (KRB_SAFE) message. Regardless, the assertion may be sentto the key distribution center server 130 either before or afterrequesting a ticket granting ticket from the key distribution centerserver 130 and/or the initial authentication exchange between thetrusted execution environment module 118 and the key distribution centerserver 130.

In some embodiments, the assertion of continuous user authenticationmonitoring sent to the key distribution center server 130 may be signedusing a user private key of a user public/private key pair generated bythe credential management module 208 on behalf of the user 102. In suchembodiments, the key distribution center server 130 may be previouslyprovided with the corresponding user public key via one or morepublic/private key exchanges between the credential management module208 and the key distribution center server 130. For example, the keydistribution center server 130 may have already received the user publickey of the user public/private key pair from a previous SIGMA keyexchange between the credential management module 208 and the keydistribution center server 130.

As discussed, the credential management module 208 may also beconfigured to request and receive a service ticket required foraccessing the service provider server 140 from the key distributioncenter server 130. To do so, in some embodiments, the credentialmanagement module 208 may first request an initial ticket (e.g., aticket granting ticket) from the key distribution center server 130. Thecredential management module 208 may receive the ticket granting ticketfrom the key distribution center server 130 in response. In embodimentswherein continuous user authentication is required, the service ticketreceived from the key distribution center server 130 may include thesigned assertion of continuous user authentication monitoring and theuser public key. In response to receiving the service ticket includingthe signed assertion of continuous user authentication monitoring andthe user public key, the credential management module 208 may requestaccess to the service provider server 140 and/or the one or moreresources provided by the service provider server 140. In someembodiments, before the user 102 and/or the client computing device 110is permitted to access the service provider server 140, the assertion ofcontinuous user authentication monitoring is verified by the serviceprovider server 140. In such embodiments, the signed assertion ofcontinuous user authentication monitoring included within the serviceticket is verified by the service provider server 140 using the userpublic key included within the service ticket. In embodiments whereinthe signed assertion of continuous user authentication monitor isverified, the client computing device 110 and/or the user 102 of theclient computing device 110 may be permitted to access the serviceprovider server 140 and/or the resources provided by the serviceprovider server 140. If, however, the signed assertion of continuoususer authentication monitor is not verified, the access request may bedropped by the service provider server 140.

Additionally, in embodiments wherein continuous user authentication isrequired by the user authentication module 206, the credentialmanagement module 208 may transmit a notification to the serviceprovider server 140 and/or the key distribution center server 130 inresponse to the user authentication module 206 determining that the user102 is no longer authenticated. For example, in some embodiments, thecredential management module 208 may transmit a notification message tothe service provider server 140 and/or the key distribution centerserver 130 indicating that the user 102 is no longer authenticated tothe client computing device 110 in response to the user authenticationmodule 206 receiving user presence data from the presence monitoringmodule 204 indicating that the user 102 is no longer located within thereference distance of the location of the client computing device 110.Additionally or alternatively, the credential management module 208 maybe configured to transmit a notification message to the service providerserver 140 and/or the key distribution center server 130 in response todetecting a change to the user authentication factors (e.g., an increaseand/or decrease in verification data strength). In such embodiments theservice provider server 140 and/or the key distribution center server130 may be configured to take preventative actions in response (e.g.,drop active connections with the client computing device 110, invalidateservice ticket, require new service ticket, etc.).

Referring now to FIG. 3, in use, the service provider server 140establishes an environment 300 during operation. The illustrativeenvironment 300 includes an assertion verification module 302 and anauthorization module 304. Each of the modules 302, 304 of theenvironment 300 may be embodied as hardware, software, firmware, or acombination thereof. It should be appreciated that the service providerserver 140 may include other components, sub-components, modules, anddevices commonly found in a server, which are not illustrated in FIG. 3for clarity of the description.

The assertion verification module 302 may facilitate verifying orotherwise validating the assertions originally provided by the trustedexecution environment module 118 of the client computing device 110. Asdiscussed, in some embodiments, the service ticket provided by the keydistribution center server 130 may include the signed assertion (e.g.,the assertion of continuous user authentication monitoring and/or theassertion of continuous user presence monitoring) originally provided bythe trusted execution environment module 118 of the client computingdevice 110. The signed assertion may be embodied as a signed SAMLassertion message and may be verified by the assertion verificationmodule 302 using the user public key, which may also be included withinthe service ticket provided by the key distribution center server 130.

Additionally, in some embodiments, the assertion verification module 302may also continue to verify one or more of the assertions originallyprovided by the trusted execution environment module 118 after initialreceipt of the service ticket including the signed assertion. Forexample, in some embodiments, the assertion verification module 302 maycontinuously monitor for messages received from the trusted executionenvironment module 118 indicative of the user 102 no longer beingauthenticated (e.g., continuous user authentication is lost) to theclient computing device 110 and/or the trusted execution environmentmodule 118. As discussed, the trusted execution environment module 118may be configured to transmit a notification message to the serviceprovider server 140 in response determining that the user 102 is nolonger authenticated. For example, in some embodiments, the assertionverification module 302 may determine that the user 102 is no longerauthenticated in response to receiving a message from the trustedexecution environment module 118 informing that the user 102 is nolonger located within the reference distance of the client computingdevice 110. Additionally or alternatively, the assertion verificationmodule 302 may determine that the user 102 is no longer authenticated inresponse to receiving a message from the trusted execution environmentmodule 118 informing of a change to one or more of the userauthentication factors (e.g., verification data).

The authorization module 304 facilitates determining whether the user102 and/or the trusted execution environment module 118 of the clientcomputing device 110 is permitted to access one or more resourcesprovided by the service provider server 140. To do so, the authorizationmodule 304 may determine which resources the user 102 and/or the trustedexecution environment module 118 is permitted to access via one or morerules or policies included within the service ticket originally providedby the key distribution center server 130. For example, in someembodiment, the service ticket originally provided by the keydistribution center server 130 may also include a privilege attributedocument (PAD) having one or more security rules and/or policies thatdefine which resources of the service provider server 140 the user 102and/or the trusted execution environment module 118 is permitted toaccess.

Referring now to FIG. 4, in use, the client computing device 110 of thesystem 100 may execute a method 400 for continuously authenticating auser via multiple authentication factors. The method 400 begins withblock 402 in which the trusted execution environment module 118 assertscontinuous user authentication monitoring to the key distribution centerserver 130. That is, the trusted execution environment module 118provides an assertion to the key distribution center server 130 that theuser's 102 authentication is being continuously monitored by the clientcomputing device 110. In some embodiments, the assertion provided to thekey distribution center server 130 may also include informationindicative of the factors (e.g., the forms of verification data) used bythe trusted execution environment module 118 to authenticate the user102. Additionally, in some embodiments, the trusted executionenvironment module 118 may also provide an assertion to the keydistribution center server 130 that the continuous presence of the user102 is being monitored in block 404. The assertion of continuous userauthentication monitoring and/or the assertion of continuous userpresence monitoring may be sent to the key distribution center server130 either before or after requesting a ticket granting ticket from thekey distribution center server 130 and/or the initial authenticationexchange between the trusted execution environment module 118 and thekey distribution center server 130. Additionally, in some embodiments,the assertion of continuous user authentication monitoring and/or theassertion of continuous user presence monitoring may be signed using auser private key of a user public/private key pair prior to being sentto the key distribution center server 130. The user public/private keypair may be generated on behalf of the user 102 by the trusted executionenvironment module 118 in some embodiments.

In block 406, the trusted execution environment module 118 may request aticket granting ticket from the key distribution center server 130. Insome embodiments, if not already completed, the key distribution centerserver 130 may establish a trust with the trusted execution environmentmodule 118 via one or more key exchanges (e.g., SIGn-and-MAc (SIGMA),Diffie-Hellman, PKINIT, etc.) prior to or contemporaneously withrequesting the ticket granting ticket from the key distribution centerserver 130. In embodiments wherein the assertion of continuous userauthentication monitoring and/or the assertion of continuous userpresence monitoring is signed using the user private key, the keydistribution center server 130 may be provided with the correspondinguser public key via the one or more key exchanges. In block 408, thetrusted execution environment module 118 receives the ticket grantingticket from the key distribution center server 130 in response. In someembodiments, the ticket granting ticket may include the signed assertionof continuous user authentication monitoring and/or the assertion ofcontinuous user presence monitoring. Such signed assertions may beembodied as one or more signed SAML messages and/or Kerberos safe(KRB_SAFE) messages in some embodiments.

In block 410, the trusted execution environment module 118 requests aservice ticket from the key distribution center server 130 forrequesting access to the service provider server 140. In someembodiments, the trusted execution environment module 118 sends theticket granting ticket along with the request for the service ticket tothe key distribution center server 130. After sending the request for aservice ticket to the key distribution center server 130, the method 400advances to block 412.

In block 412, the trusted execution environment module 118 receives theservice ticket needed to access the service provider server 140 from thekey distribution center server 130. In some embodiments, the serviceticket includes the signed assertions (e.g., the assertion of continuoususer authentication monitoring and/or the assertion of continuous userpresence monitoring). Additionally, in some embodiments the serviceticket received from the key distribution center server 130 alsoincludes the user public key of the user public/private key pair. Asdiscussed, the key distribution center server 130 may be previouslyprovided with the user public key during a prior key exchange with thetrusted execution environment module 118 (e.g., a SIGMA session, PKINIT,etc.).

In block 414, the trusted execution environment module 118 requestsaccess to the service provider server 140 and/or one or more resourcesprovided by the service provider server 140 on behalf of the user 102.To do so, the trusted execution environment module 118 sends the serviceticket obtained from the key distribution center server 130 to theservice provider server 140. As discussed, the service ticket obtainedfrom the key distribution center server 130 includes the signedassertions originally provided by the trusted execution environmentmodule 118. The service ticket also includes the user public key of theuser public/private key pair generated by the trusted executionenvironment module 118.

At block 416, before the user 102, the trusted execution environmentmodule 118, and/or the client computing device 110 is permitted toaccess the service provider server 140, it is determined whether theassertion of continuous user authentication monitoring is verified. Insuch embodiments, the signed assertion of continuous user authenticationmonitoring included within the service ticket is verified by the serviceprovider server 140 using the user public key included within theservice ticket. In embodiments wherein the signed assertion ofcontinuous user authentication monitoring is verified by the serviceprovider server 140, the client computing device 110, the trustedexecution environment module 118, and/or the user 102 of the clientcomputing device 110 may be permitted to access the service providerserver 140 and/or the resources provided by the service provider server140 in block 418. If, however, the signed assertion of continuous userauthentication monitor is not verified by the service provider server140, the access request may be dropped by the service provider server140 in block 420.

Referring now to FIG. 5, in use, the client computing device 110 of thesystem 100 may execute a method 500 for monitoring continuous userauthentication. The method 500 begins with block 502 in which thetrusted execution environment module 118 authenticates the user 102using one or more authentication factors (e.g., verification dataprovided by the user 102). For example, the user 102 may be required toprovide multiple authentication factors (e.g., multiple forms ofverification data) to the client computing device 110 in order to provetheir identity. The verification data may include data provided by theuser 102 via one or more user inputs (e.g., a keyboard, touchpad, touchscreen, wireless communication devices, etc.), data received from theone or more sensors 126, and/or user presence data received from thepresence monitoring module 204.

In block 504, the trusted execution environment module 118 monitors thecontinuous authentication of the user 102. For example, in someembodiments, the trusted execution environment module 118 monitors forchanges to the user's 102 authentication factors (e.g., increases instrength, decreases in strength, replacements, etc.). Additionally, thetrusted execution environment module 118 may monitor for informationindicative of the user 102 no longer being present within a referencedistance of the client computing device 110. In block 506, the trustedexecution environment module 118 determines whether continuous userauthentication exists. That is, the trusted execution environment module118 determines whether the user 102 should still be authenticated to theclient computing device 110. In some embodiments, the trusted executionenvironment module 118 may determine that the user 102 should no longerbe authenticated to the client computing device 110 in response todetermining that a change to the user's 102 authentication factors hasoccurred and/or that the user 102 is no longer located within thereference distance of the client computing device 110. If, in block 506,the trusted execution environment module 118 determines that the user102 should no longer be authenticated to the client computing device110, the method 500 advances to block 508 in which the trusted executionenvironment module 118 notifies the service provider server 140 of theloss of continuous user authentication. If, however, the trustedexecution environment module 118 determines that the user 102 shouldstill be authenticated to the client computing device 110, the method500 loops back to block 504 in which the trusted execution environmentmodule 118 continues monitoring the continuous authentication of theuser 102.

Referring now to FIG. 6, a simplified activity flow diagram of at leastone embodiment of the methods 400, 500 of FIGS. 4 and 5 for continuouslyauthenticating a user via multiple authentication factors isillustratively shown. In data flow 602, the trusted executionenvironment module 118 may establish a trust with the key distributioncenter server 130. To do so, the trusted execution environment module118 and the key distribution center server 130 may perform one or morekey exchanges (e.g., SIGMA sessions, Diffie-Hellman, etc.). In someembodiments, in data flow 602, the trusted execution environment module118 may also enroll a user public key of a user public/private key pair,which may be generated by the trusted execution environment module 118on behalf of the user 102.

In data flow 604, the user 102 may be required to authenticate to thetrusted execution environment module 118 using one or moreauthentication factors. In some embodiments, in data flow 604, the user102 may be required to use multiple authentication factors to provetheir identity to the trusted execution environment module 118. In dataflow 606, the trusted execution environment module 118 may continuouslymonitor the presence of the user 102 with respect to the clientcomputing device 110. It should be appreciated that although the trustedexecution environment module 118 is shown in the illustrative embodimentas continuously monitoring the presence of the user 102 in data flow606, the trusted execution environment module 118 may continuouslymonitor the presence of the user 102 at any time before or after dataflow 606. That is, the trusted execution environment module 118 maymonitor the presence of the user 102 during any of the data flows602-622 illustratively shown in FIG. 6.

In data flow 608, the trusted execution environment module 118 mayrequest an initial ticket from the key distribution center server 130.To facilitate secure communications between the trusted executionenvironment module 118 and the key distribution center server 130 mayperform a secure key exchange. For example, in data flow 608, thetrusted execution environment module 118 and the key distribution centerserver 130 may exchange public/private key pairs via PKINT for initialauthentication. Additionally, in some embodiments, the trusted executionenvironment module 118 may generate and send an assertion to the keydistribution center server 130 that the continuous authentication of theuser 102 is being performed. In some embodiments, the assertion sent bythe trusted execution environment module 118 to the key distributioncenter server 130 may be embodied as a SAML assertion message. The SAMLassertion message may be signed with the user private key of the userpublic/private key pair previously generated by the trusted executionenvironment module 118. In data flow 610, the key distribution centerserver 130 may generate and send a ticket granting ticket to the trustedexecution environment module 118 in response to the request. In someembodiments, in data flow 610, the ticket granting ticket generated andsent by the key distribution center server 130, may include the signedSAML assertion message originally received from the trusted executionenvironment module 118.

In response to receiving the ticket granting ticket from the keydistribution center server 130, the trusted execution environment module118 may generate and send a request for a service ticket to the keydistribution center server 130 in data flow 612. The request may includethe ticket granting ticket received from the key distribution centerserver 130 in some embodiments. In data flow 614, the key distributioncenter server 130 may generate and transmit the requested service ticketto the trusted execution environment module 118. The service ticket mayinclude the signed SAML assertion message and, in some embodiments, theuser public key originally generated by the trusted executionenvironment module 118. In data flow 616, the trusted executionenvironment module 118 may subsequently request access to the serviceprovider server 140 and/or a resource provided by the service providerserver 140 using the service ticket received from the key distributioncenter server 130. As discussed, the service ticket received from thekey distribution center server 130 may include the signed SAML assertionmessage and the user public key generated by the trusted executionenvironment module 118.

In data flow 618, the service provider server 140 may verify the signedSAML assertion included within the service ticket. To do so, the serviceprovider server 140 may use the user public key, which was also includedwithin the service ticket, to verify the signed SAML assertion message.If the service provider server 140 verifies that the signed SAMLassertion is valid, the service provider server 140 may grant access tothe trusted execution environment module 118 and/or the user 102 in dataflow 620. In some embodiments, the service ticket provided by the keydistribution center server 130 may include an expiration time. That is,in some embodiments, the service ticket may be configured to expireafter a reference amount of time. It should be understood, however, thatthe service ticket may also be configured to expire according to anyother condition or event. For example, in some embodiments, the serviceticket may be configured to expire after a reference number of accessrequests by the trusted execution environment module 118.

Additionally or alternatively, in some embodiments, the trustedexecution environment module 118 may be configured to allow a serviceticket to expire in data flow 622. For example, in embodiments whereinthe trusted execution environment module 118 determines that continuoususer authentication has been lost (e.g., determining that the user 102is no longer located with the reference distance of the client computingdevice 110 and/or determining that one or more authentication factorshas changed), the trusted execution environment module 118 may determinenot to renew the service ticket required to access the service providerserver 140. In doing so, the service ticket will expire as discussedabove. Additionally, in some embodiments, the trusted executionenvironment module 118 may be configured to notify the service providerserver 140 that continuous user authentication has been lost prior tothe expiration of the service ticket. In such embodiments, the trustedexecution environment module 118 may send a KRB_SAFE message to theservice provider server 140 informing of the loss of continuous userauthentication.

In some embodiments, the trusted execution environment module 118 mayrequest access to the service provider server 140 and/or a resourceprovided by the service provider server 140 without first obtaining aservice ticket from the key distribution center server 130. For example,in some embodiments the trusted execution environment module 118 mayrequest access to the service provider server 140 and/or a resourceprovided by the service provider server 140 prior to the occurrence ofany one of data flows 602-614. In such embodiments, the service providerserver 140 may request a service ticket be provided by the trustedexecution environment module 118 prior to granting access. Subsequently,the trusted execution environment module 118 may request, from the keydistribution center server 130, the service ticket required to accessthe service provider server 140. In response, the service providerserver 140 may generate and transmit the requested service ticket to thetrusted execution environment module 118. The service ticket may includea signed SAML assertion message previously provided by the trustedexecution environment module 118 and, in some embodiments, a user publickey corresponding to a user private key used by the trusted executionenvironment module 118 to sign the SAML assertion message. The trustedexecution environment module 118 may subsequently re-request access tothe service provider server 140 and/or the resource provided by theservice provider server 140 using the service ticket received from thekey distribution center server 130.

Referring now to FIG. 7, a simplified activity flow diagram of anotherembodiment of the methods 400, 500 of FIGS. 4 and 5 for continuouslyauthenticating a user via multiple authentication factors isillustratively shown. In data flow 702, the user 102 may be required toauthenticate to the trusted execution environment module 118 using oneor more authentication factors. In some embodiments, in data flow 702,the user 102 may be required to use multiple authentication factors toprove their identity to the trusted execution environment module 118. Indata flow 704, the trusted execution environment module 118 maycontinuously monitor the presence of the user 102 relative to the clientcomputing device 110. It should be appreciated that although the trustedexecution environment module 118 is shown in the illustrative embodimentas continuously monitoring the presence of the user 102 in data flow704, the trusted execution environment module 118 may continuouslymonitor the presence of the user 102 at any time before or after dataflow 704. That is, the trusted execution environment module 118 maymonitor the presence of the user 102 during any of the data flows702-722 illustratively shown in FIG. 7.

In some embodiments, the trusted execution environment module 118 maygenerate a user public/private key pair on behalf of the user 102. Insuch embodiments, the trusted execution environment module 118 mayenroll the user public key of the user public/private key pair with thekey distribution center server 130 in data flow 706. To do so, thetrusted execution environment module 118 may initiate one or more SIGMAsessions with the key distribution center server 130. In someembodiments, the trusted execution environment module 118 may alsogenerate and send, in data flow 706, an assertion to the keydistribution center server 130 that the continuous authentication of theuser 102 is being monitored. The assertion sent by the trusted executionenvironment module 118 to the key distribution center server 130 may besigned with the user private key of the user public/private key pairpreviously generated by the trusted execution environment module 118.

Subsequently, in data flow 708, the trusted execution environment module118 may request an initial ticket from the key distribution centerserver 130. To facilitate secure communications between the trustedexecution environment module 118 and the key distribution center server130 may perform a secure key exchange. For example, in data flow 708,the trusted execution environment module 118 and the key distributioncenter server 130 may exchange public/private key pairs via PKINT forinitial authentication.

In data flow 710, the key distribution center server 130 may generateand send a ticket granting ticket to the trusted execution environmentmodule 118 in response to the request from the trusted executionenvironment module 118. In some embodiments, in data flow 710, theticket granting ticket generated and sent by the key distribution centerserver 130 may include the signed assertion message originally receivedfrom the trusted execution environment module 118. Additionally, in someembodiments, the ticket granting ticket may include a privilegeattribute document (PAD), which may define which resources of theservice provider server 140 the user 102 and/or the trusted executionenvironment module 118 is permitted to access.

In response to receiving the ticket granting ticket from the keydistribution center server 130, the trusted execution environment module118 may generate and send a request for a service ticket to the keydistribution center server 130 in data flow 712. The request may includethe ticket granting ticket received from the key distribution centerserver 130 in some embodiments. In data flow 714, the key distributioncenter server 130 may generate and transmit the requested service ticketto the trusted execution environment module 118. The service ticket mayinclude the signed assertion message and, in some embodiments, the PADand the user public key originally generated by the trusted executionenvironment module 118. In data flow 716, the trusted executionenvironment module 118 may subsequently request access to the serviceprovider server 140 and/or a resource provided by the service providerserver 140 using the service ticket received from the key distributioncenter server 130. As discussed, the service ticket received from thekey distribution center server 130 may include the signed assertionmessage, the user public key generated by the trusted executionenvironment module 118, and the PAD.

In data flow 718, the service provider server 140 may verify the PADincluded within the service ticket. Additionally or alternatively, theservice provider server 140 may verify the signed assertion messageincluded within the service ticket. To do so, the service providerserver 140 may use the user public key, which was also included withinthe service ticket, to verify the signed assertion message. If theservice provider server 140 verifies that the PAD and/or the signedassertion message is valid, the service provider server 140 may grantaccess to a requested resource by the trusted execution environmentmodule 118 and/or the user 102 in data flow 720. Additionally, in someembodiments, the trusted execution environment module 118 may beconfigured to notify the service provider server 140 in response todetermining that continuous user authentication no longer exists (e.g.,determining that the user 102 is no longer located with the referenceproximity distance from the client computing device 110 and/ordetermining that one or more authentication factors has changed). Insuch embodiments, the trusted execution environment module 118 may senda KRB_SAFE message to the service provider server 140 informing of theloss of continuous user authentication in data flow 722.

Additionally or alternatively, in some embodiments, the trustedexecution environment module 118 may be configured to allow servicetickets to expire. For example, in embodiments wherein the trustedexecution environment module 118 determines that continuous userauthentication has been lost (e.g., determining that the user 102 is nolonger located with the reference proximity distance from the clientcomputing device 110 and/or determining that one or more authenticationfactors has changed), the trusted execution environment module 118 maydetermine not to renew the service ticket required to access the serviceprovider server 140. In doing so, the service ticket will expire asdiscussed above. The trusted execution environment module 118 may alsobe configured to delete service tickets in response to determining thatcontinuous user authentication has been lost.

Additionally, in some embodiments, the trusted execution environmentmodule 118 may be configured to periodically (e.g., at referenceintervals) send notifications to the service provider server 140 and/orthe key distribution center server 130. For example, the trustedexecution environment module 118 may send a KRB_SAFE message to theservice provider server 140 and/or the key distribution center server130 according to the reference interval. In that way, denial of serviceattacks may be mitigated.

Referring now to FIG. 8, a simplified activity flow diagram of yetanother embodiment of the methods 400, 500 of FIGS. 4 and 5 forcontinuously authenticating a user via multiple authentication factorsis illustratively shown. In data flow 802, the user 102 may be requiredto authenticate to the trusted execution environment module 118 usingone or more authentication factors. In some embodiments, in data flow802, the user 102 may be required to use multiple authentication factorsto prove their identity to the trusted execution environment module 118.In data flow 804, the trusted execution environment module 118 maycontinuously monitor the presence of the user 102 relative to the clientcomputing device 110. It should be appreciated that although the trustedexecution environment module 118 is shown in the illustrative embodimentas continuously monitoring the presence of the user 102 in data flow804, the trusted execution environment module 118 may continuouslymonitor the presence of the user 102 at any time before or after dataflow 804. That is, the trusted execution environment module 118 maymonitor the presence of the user 102 during any of the data flows802-822 illustratively shown in FIG. 8.

In data flow 806, the trusted execution environment module 118 mayrequest an initial ticket from the key distribution center server 130.To facilitate secure communications between the trusted executionenvironment module 118 and the key distribution center server 130 mayperform a secure key exchange. For example, in data flow 806, thetrusted execution environment module 118 and the key distribution centerserver 130 may exchange public/private key pairs via PKINT for initialauthentication.

In data flow 808, the key distribution center server 130 may generateand send a ticket granting ticket to the trusted execution environmentmodule 118 in response to the request from the trusted executionenvironment module 118. Subsequently, in data flow 810, the trustedexecution environment module 118 may send one or more KRB_SAFE messagesto the key distribution center server 130. In some embodiments, the oneor more KRB_SAFE message may include an attestation of the trustedexecution environment module 118 to the key distribution center server130 and proof that a PKINT private key is being protected by the trustedexecution environment module 118. In doing so, a trust may beestablished between the trusted execution environment module 118 and thekey distribution center server 130. Additionally, in some embodiments,one or more of the KRB_SAFE message sent to the key distribution centerserver 130 may also include an assertion generated by the trustedexecution environment module 118 indicating that the continuousauthentication of the user 102 is being monitored. In some embodimentsthe one or more KRB_SAFE messages may be sent according to a SIGMAprotocol. It should be appreciated that in such embodiments, data flow810 may be embodied as three (or more) communication exchanges betweenthe trusted execution environment module 118 and the key distributioncenter server 130 rather than one as illustratively shown in FIG. 8.

As discussed, in some embodiments, the one or more KRB_SAFE messagessent to the key distribution center server 130 may include an assertiongenerated by the trusted execution environment module 118 indicatingthat the continuous authentication of the user 102 is being monitored.In such embodiments, the assertion may be signed with a user private keyof a user public/private key pair generated by the trusted executionenvironment module 118 on behalf of the user 102 or it may be signed bya PKINT private key. In embodiments wherein the assertion is signed witha user private key of a user public/private key pair generated by thetrusted execution environment module 118, the corresponding user publickey of the user public/private key pair may be enrolled with the keydistribution center server 130.

The trusted execution environment module 118 may thereafter generate andsend a request for a service ticket to the key distribution centerserver 130 in data flow 812. The request may include the ticket grantingticket received from the key distribution center server 130 in someembodiments. In data flow 814, the key distribution center server 130may generate and transmit the requested service ticket to the trustedexecution environment module 118. The service ticket may include thesigned assertion message and, in some embodiments, a privilege attributedocument (PAD) and a public key, which corresponds to the private keyused to sign the assertion message. The PAD may define which resourcesof the service provider server 140 the user 102 and/or the trustedexecution environment module 118 is permitted to access.

In data flow 816, the trusted execution environment module 118 maysubsequently request access to the service provider server 140 and/or aresource provided by the service provider server 140 using the serviceticket received from the key distribution center server 130. Asdiscussed, the service ticket received from the key distribution centerserver 130 may include the signed assertion message, the public key, andthe PAD.

In data flow 818, the service provider server 140 may verify the PADincluded within the service ticket. Additionally or alternatively, theservice provider server 140 may verify the signed assertion messageincluded within the service ticket. To do so, the service providerserver 140 may use the public key, which was also included within theservice ticket, to verify the signed assertion message. If the serviceprovider server 140 verifies that the PAD and/or the signed assertionmessage is valid, the service provider server 140 may grant access to arequested resource by the trusted execution environment module 118and/or the user 102 in data flow 820. Additionally, in some embodiments,the trusted execution environment module 118 may be configured to notifythe service provider server 140 in response to determining thatcontinuous user authentication no longer exists (e.g., determining thatthe user 102 is no longer located with the reference proximity distancefrom the client computing device 110 and/or determining that one or moreauthentication factors has changed). In such embodiments, the trustedexecution environment module 118 may send a KRB_SAFE message to theservice provider server 140 informing of the loss of continuous userauthentication in data flow 822.

Additionally or alternatively, in some embodiments, the trustedexecution environment module 118 may be configured to allow servicetickets to expire. For example, in embodiments wherein the trustedexecution environment module 118 determines that continuous userauthentication has been lost (e.g., determining that the user 102 is nolonger located with the reference proximity distance from the clientcomputing device 110 and/or determining that one or more authenticationfactors has changed), the trusted execution environment module 118 maydetermine not to renew the service ticket required to access the serviceprovider server 140. In doing so, the service ticket will expire asdiscussed above. The trusted execution environment module 118 may alsobe configured to delete service tickets in response to determining thatcontinuous user authentication has been lost.

Additionally, in some embodiments, the trusted execution environmentmodule 118 may be configured to periodically (e.g., at referenceintervals) send notifications to the service provider server 140 and/orthe key distribution center server 130. For example, the trustedexecution environment module 118 may send a KRB_SAFE message to theservice provider server 140 and/or the key distribution center server130 according to the reference interval. In that way, denial of serviceattacks may be mitigated.

Referring now to FIG. 9, a simplified activity flow diagram of yetanother embodiment of the methods 400, 500 of FIGS. 4 and 5 forcontinuously authenticating a user via multiple authentication factorsis illustratively shown. In data flow 902, the trusted executionenvironment module 118 may establish a trust with the key distributioncenter server 130. To do so, the trusted execution environment module118 and the key distribution center server 130 may perform one or morekey exchanges (e.g., SIGMA sessions, Diffie-Hellman, etc.) In someembodiments, in data flow 902, the trusted execution environment module118 may also enroll a user public key of a user public/private key pair,which may be generated by the trusted execution environment module 118on behalf of the user 102.

In data flow 904, the user 102 may be required to authenticate to thetrusted execution environment module 118 using one or moreauthentication factors. In some embodiments, in data flow 904, the user102 may be required to use multiple authentication factors to provetheir identity to the trusted execution environment module 118. In dataflow 906, the trusted execution environment module 118 may continuouslymonitor the presence of the user 102 with respect to the clientcomputing device 110. It should be appreciated that although the trustedexecution environment module 118 is shown in the illustrative embodimentas continuously monitoring the presence of the user 102 in data flow906, the trusted execution environment module 118 may continuouslymonitor the presence of the user 102 at any time before or after dataflow 906. That is, the trusted execution environment module 118 maymonitor the presence of the user 102 during any of the data flows902-924 illustratively shown in FIG. 9.

In data flow 908, the trusted execution environment module 118 mayrequest an initial ticket from the key distribution center server 130.To facilitate secure communications between the trusted executionenvironment module 118 and the key distribution center server 130 mayperform a secure key exchange. For example, in data flow 908, thetrusted execution environment module 118 and the key distribution centerserver 130 may exchange public/private key pairs via PKINT for initialauthentication. In data flow 910, the key distribution center server 130may generate and send a ticket granting ticket to the trusted executionenvironment module 118 in response to the request from the trustedexecution environment module 118.

The trusted execution environment module 118 may thereafter generate andsend a request for a service ticket to the key distribution centerserver 130 in data flow 912. The request may include the ticket grantingticket received from the key distribution center server 130 in someembodiments. In data flow 914, the key distribution center server 130may generate and transmit the requested service ticket to the trustedexecution environment module 118. The service ticket may include aprivilege attribute document (PAD) and the user public key of the userpublic/private key pair, which was previously generated by the trustedexecution environment module 118.

In data flow 916, the trusted execution environment module 118 maysubsequently request access to the service provider server 140 and/or aresource provided by the service provider server 140 using the serviceticket received from the key distribution center server 130. Asdiscussed, the service ticket received from the key distribution centerserver 130 may include the PAD and the user public key. In response toreceiving the request for access, the service provider server 140 may beconfigured to determine that authentication is required by the trustedexecution environment module 118 in data flow 918. If the serviceprovider server 140 determines that authentication is required, thetrusted execution environment module 118 and/or the user 102 may beauthenticated via one or more SAML messages (e.g., data flows 920-926)between the trusted execution environment module 118 and the serviceprovider server 140. For example, in some embodiments, the serviceprovider server 140 may send a SAML authentication request to thetrusted execution environment module 118 in data flow 920. Subsequently,in data flow 922, the trusted execution environment module 118 may senda SAML authentication response to the service provider server 140.

In some embodiments, in data flow 924, the service provider server 140may also request the trusted execution environment module 118 toperiodically (e.g., at reference intervals) send SAML keepalive messagesto facilitate mitigating denial of service attacks. Such keepalivemessages may be required by the service provider server 140 based atleast in part on, or otherwise as a function of, the PAD generated bythe key distribution center server 130. In response to receiving such arequest, the trusted execution environment module 118 may periodically(e.g., at reference intervals) send a SAML keepalive message to theservice provider server 140 in data flow 926. In some embodiments, oneor more KRB_SAFE message exchanges may be used to communicate the one ormore SAML messages (e.g., data flows 920-926) between the trustedexecution environment module 118 and the service provider server 140.

In some embodiments, the trusted execution environment module 118 may beconfigured to stop sending SAML keepalive messages to the serviceprovider server 140. For example, in some embodiments, the trustedexecution environment module 118 may be configured to stop sending SAMLkeepalive messages to the service provider server 140 in response todetermining that continuous user authentication has been lost (e.g.,determining that the user 102 is no longer located with the referenceproximity distance from the client computing device 110 and/ordetermining that one or more authentication factors has changed). Insuch embodiments, the service provider server 140 may be configured toprevent access by the trusted execution environment module 118 and/orthe user 102 after a reference number of expected SAML keepalivemessages are not received and/or after the expiration of a timer (e.g.,expiration of a reference time-out period).

Additionally or alternatively, in some embodiments, the trustedexecution environment module 118 may be configured to delete servicetickets. For example, in embodiments wherein the trusted executionenvironment module 118 determines that continuous user authenticationhas been lost (e.g., determining that the user 102 is no longer locatedwith the reference proximity distance from the client computing device110 and/or determining that one or more authentication factors haschanged), the trusted execution environment module 118 may delete orotherwise invalidate the service ticket required to access the serviceprovider server 140. In doing so, further access to the service providerserver 140 by the trusted execution environment module 118 and/or theuser 102 may be prevented.

Illustrative examples of the technologies disclosed herein are providedbelow. An embodiment of the technologies may include any one or more,and any combination of the examples described below.

Example 1 includes a computing device to continuously authenticate auser via multiple authentication factors, the computing device includesa trusted execution environment module to (i) generate a continuousauthentication assertion to indicate that continuous authentication of auser is monitored; (ii) send the continuous authentication assertion toa key distribution center server; (iii) request an initial ticket fromthe key distribution center server; (iv) receive the initial ticket fromthe key distribution center server; (v) request a service ticket fromthe key distribution center server required to access a service providerserver; (vi) receive the service ticket from the key distribution centerserver required to access the service provider server, wherein theservice ticket includes the continuous authentication assertion; (vii)request access to the service provider server with the service ticket;and (viii) access the service provider server in response toverification of the continuous authentication assertion.

Example 2 includes the subject matter of Example 1, and wherein thetrusted execution environment module is further to (i) authenticate theuser via a plurality of authentication factors; (ii) monitor thecontinuous authentication of the user; (iii) determine whether the usershould still be authenticated; and (iv) notify the service providerserver of a loss of the continuous authentication of the user inresponse to a determination that the user should no longer beauthenticated.

Example 3 includes the subject matter of any of Examples 1 and 2, andwherein to notify the service provider server of a loss of thecontinuous authentication of the user includes to send a notificationmessage to the service provider server to inform of the loss of thecontinuous authentication of the user.

Example 4 includes the subject matter of any of Examples 1-3, andwherein the notification message includes a Kerberos message.

Example 5 includes the subject matter of any of Examples 1-4, andwherein the Kerberos message includes a Kerberos safe message.

Example 6 includes the subject matter of any of Examples 1-5, andwherein the trusted execution environment module is further to deletethe service ticket in response to the determination that the user shouldno longer be authenticated.

Example 7 includes the subject matter of any of Examples 1-6, andwherein the trusted execution environment module is further to permitthe service ticket to expire in response to the determination that theuser should no longer be authenticated.

Example 8 includes the subject matter of any of Examples 1-7, andwherein to permit the service ticket to expire includes to not renew theservice ticket in response to the determination that the user should nolonger be authenticated.

Example 9 includes the subject matter of any of Examples 1-8, andfurther including one or more sensors to capture user characteristicdata; and wherein to authenticate the user via a plurality ofauthentication factors includes to authenticate the user as a functionof the user characteristic data captured by the one or more sensors.

Example 10 includes the subject matter of any of Examples 1-9, andwherein the trusted execution environment module is further to (i)monitor a presence of the user relative to the computing device; (ii)generate a continuous presence assertion to indicate that continuouspresence of the user relative to the computing device is monitored;(iii) send the continuous presence assertion to the key distributioncenter server; (iv) determine whether the user is present relative tothe computing device; and (iv) notify the service provider server of aloss of the continuous presence of the user relative to the computingdevice in response to a determination that the user is not presentrelative to the computing device.

Example 11 includes the subject matter of any of Examples 1-10, andwherein to notify the service provider server of a loss of thecontinuous presence of the user relative to the computing deviceincludes to send a notification message to the service provider serverto inform of the loss of the continuous presence of the user relative tothe computing device.

Example 12 includes the subject matter of any of Examples 1-11, andwherein the notification message includes a Kerberos safe message.

Example 13 includes the subject matter of any of Examples 1-12, andwherein the trusted execution environment module is further to send aKerberos safe message to the service provider server at a referenceinterval.

Example 14 includes the subject matter of any of Examples 1-13, andwherein the trusted execution environment module is further to (i)generate a user key pair on behalf of the user, wherein the user keypair includes a user public key and a user private key generated onbehalf of the user; (ii) provide the user public key to the keydistribution center server via a secure key exchange; and (iii) sign thecontinuous authentication assertion with the user private key prior tothe continuous authentication assertion being sent to the keydistribution center server; and wherein to send the continuousauthentication assertion to the key distribution center server includesto send the signed continuous authentication assertion to the keydistribution center server; and wherein the service ticket received fromthe key distribution center server includes the signed continuousauthentication assertion and the user public key.

Example 15 includes the subject matter of any of Examples 1-14, andwherein to provide the user public key to the key distribution centerserver via a secure key exchange includes to provide the user public keyto the key distribution center server via a SIGn-and-MAc session.

Example 16 includes the subject matter of any of Examples 1-15, andwherein the service ticket received from the key distribution centerserver further includes a privilege attribute document, the privilegeattribute document includes one or more policies required to access theservice provider server.

Example 17 includes the subject matter of any of Examples 1-16, andwherein to request an initial ticket from the key distribution centerserver includes to request a ticket granting ticket from the keydistribution center server; and wherein to receive the initial ticketfrom the key distribution center server includes to receive the ticketgranting ticket from the key distribution center server.

Example 18 includes the subject matter of any of Examples 1-17, andwherein the continuous authentication assertion includes at least one ofa Kerberos safe message or a security assertion markup language message.

Example 19 includes a method for continuously authenticating a user viamultiple authentication factors, the method includes (i) generating, ona trusted execution environment module of a computing device, acontinuous authentication assertion indicating that continuousauthentication of a user is being monitored; (ii) sending, on thetrusted execution environment module, the continuous authenticationassertion to a key distribution center server; (iii) requesting, on thetrusted execution environment module, an initial ticket from the keydistribution center server; (iv) receiving, on the trusted executionenvironment module, the initial ticket from the key distribution centerserver; (v) requesting, on the trusted execution environment module, aservice ticket from the key distribution center server for accessing aservice provider server; (vi) receiving, on the trusted executionenvironment module, the service ticket from the key distribution centerserver for accessing the service provider server, wherein the serviceticket includes the continuous authentication assertion; (vii)requesting, on the trusted execution environment module, access to theservice provider server with the service ticket includes the continuousauthentication assertion; and (viii) accessing, on the trusted executionenvironment module, the service provider server in response to thecontinuous authentication assertion being verified.

Example 20 includes the subject matter of Example 19, and furtherincludes (i) authenticating, on the trusted execution environmentmodule, the user via a plurality of authentication factors; (ii)monitoring, on the trusted execution environment module, the continuousauthentication of the user; (iii) determining, on the trusted executionenvironment module, whether the user should still be authenticated; and(iv) notifying, on the trusted execution environment module, the serviceprovider server of a loss of the continuous authentication of the userin response to determining that the user should no longer beauthenticated.

Example 21 includes the subject matter of any of Examples 19 and 20, andwherein notifying the service provider server of a loss of thecontinuous authentication of the user includes sending a notificationmessage to the service provider server informing of the loss of thecontinuous authentication of the user.

Example 22 includes the subject matter of any of Examples 19-21, andwherein the notification message includes a Kerberos safe message.

Example 23 includes the subject matter of any of Examples 19-22, andfurther includes deleting, on the trusted execution environment module,the service ticket in response to determining that the user should nolonger be authenticated.

Example 24 includes the subject matter of any of Examples 19-23, andfurther includes permitting, on the trusted execution environmentmodule, the service ticket to expire in response to determining that theuser should no longer be authenticated.

Example 25 includes the subject matter of any of Examples 19-24, andwherein permitting the service ticket to expire includes not renewingthe service ticket in response to determining that the user should nolonger be authenticated.

Example 26 includes the subject matter of any of Examples 19-25, andfurther includes receiving, on the trusted execution environment module,user characteristic data captured by one or more sensors; and whereinauthenticating the user via a plurality of authentication factorsincludes authenticating user as a function of the user characteristicdata captured by the one or more sensors.

Example 27 includes the subject matter of any of Examples 19-26, andfurther includes (i) monitoring, on the trusted execution environmentmodule, a presence of the user relative to the computing device; (ii)generating, on the trusted execution environment module, a continuouspresence assertion indicating that continuous presence of the userrelative to the computing device is being monitored; (iii) sending, onthe trusted execution environment module, the continuous presenceassertion to the key distribution center server; (iv) determining, onthe trusted execution environment module, whether the user is presentrelative to the computing device; and (v) notifying, on the trustedexecution environment module, the service provider server of a loss ofthe continuous presence of the user relative to the computing device inresponse to determining that the user is not present relative to thecomputing device.

Example 28 includes the subject matter of any of Examples 19-27, andwherein notifying the service provider server of a loss of thecontinuous presence of the user relative to the computing deviceincludes sending a notification message to the service provider serverinforming of the loss of the continuous presence of the user relative tothe computing device.

Example 29 includes the subject matter of any of Examples 19-28, andwherein the notification message includes a Kerberos safe message.

Example 30 includes the subject matter of any of Examples 19-29, andfurther includes sending, on the trusted execution environment module, aKerberos safe message to the service provider server at a referenceinterval.

Example 31 includes the subject matter of any of Examples 19-30, andfurther includes (i) generating, on the trusted execution environmentmodule, a user key pair on behalf of the user, wherein the user key pairincludes a user public key and a user private key generated on behalf ofthe user; (ii) providing, on the trusted execution environment module,the user public key to the key distribution center server via a securekey exchange; and (iii) signing, on the trusted execution environmentmodule, the continuous authentication assertion with the user privatekey prior to sending the continuous authentication assertion to the keydistribution center server; and wherein sending the continuousauthentication assertion to the key distribution center server includessending the signed continuous authentication assertion to the keydistribution center server; and wherein the service ticket received fromthe key distribution center server includes the signed continuousauthentication assertion and the user public key.

Example 32 includes the subject matter of any of Examples 19-31, andwherein providing the user public key to the key distribution centerserver via a secure key exchange includes providing the user public keyto the key distribution center server via a SIGn-and-MAc session.

Example 33 includes the subject matter of any of Examples 19-32, andwherein the service ticket received from the key distribution centerserver further includes a privilege attribute document, the privilegeattribute document includes one or more policies required for accessingthe service provider server.

Example 34 includes the subject matter of any of Examples 19-33, andwherein requesting an initial ticket from the key distribution centerserver includes requesting a ticket granting ticket from the keydistribution center server; and wherein receiving the initial ticketfrom the key distribution center server includes receiving the ticketgranting ticket from the key distribution center server.

Example 35 includes the subject matter of any of Examples 19-34, andwherein the continuous authentication assertion includes at least one ofa Kerberos safe message or a security assertion markup language message.

Example 36 includes a computing device to continuously authenticate auser via multiple authentication factors, the computing device includesa processor; and a memory having stored therein a plurality ofinstructions that when executed by the processor cause the computingdevice to perform the method of any of Examples 19-35.

Example 37 includes one or more machine readable media including aplurality of instructions stored thereon that in response to beingexecuted result in a computing device performing the method of any ofExamples 19-35.

Example 38 includes a computing device to continuously authenticate auser via multiple authentication factors, the computing device includesmeans for performing the method of any of Examples 19-35.

Example 39 includes a computing device to continuously authenticate auser via multiple authentication factors, the computing device includesa processor; and a memory having stored therein a plurality ofinstructions that when executed by the processor cause the computingdevice to (i) generate a continuous authentication assertion to indicatethat continuous authentication of a user is monitored; (ii) send thecontinuous authentication assertion to a key distribution center server;(iii) request an initial ticket from the key distribution center server;(iv) receive the initial ticket from the key distribution center server;(v) request a service ticket from the key distribution center serverrequired to access a service provider server; (vi) receive the serviceticket from the key distribution center server required to access theservice provider server, wherein the service ticket includes thecontinuous authentication assertion; (vii) request access to the serviceprovider server with the service ticket; and (viii) access the serviceprovider server in response to verification of the continuousauthentication assertion.

Example 40 includes the subject matter of Example 39, and wherein theplurality of instructions further cause the computing device to (i)authenticate the user via a plurality of authentication factors; (ii)monitor the continuous authentication of the user; (iii) determinewhether the user should still be authenticated; and (iv) notify theservice provider server of a loss of the continuous authentication ofthe user in response to a determination that the user should no longerbe authenticated.

Example 41 includes the subject matter of any of Examples 39 and 40, andwherein to notify the service provider server of a loss of thecontinuous authentication of the user includes to send a notificationmessage to the service provider server to inform of the loss of thecontinuous authentication of the user.

Example 42 includes the subject matter of any of Examples 39-41, andwherein the notification message includes a Kerberos message.

Example 43 includes the subject matter of any of Examples 39-42, andwherein the Kerberos message includes a Kerberos safe message.

Example 44 includes the subject matter of any of Examples 39-43, andwherein the plurality of instructions further cause the computing deviceto delete the service ticket in response to the determination that theuser should no longer be authenticated.

Example 45 includes the subject matter of any of Examples 39-44, andwherein the plurality of instructions further cause the computing deviceto permit the service ticket to expire in response to the determinationthat the user should no longer be authenticated.

Example 46 includes the subject matter of any of Examples 39-45, andwherein to permit the service ticket to expire includes to not renew theservice ticket in response to the determination that the user should nolonger be authenticated.

Example 47 includes the subject matter of any of Examples 39-46, andfurther includes one or more sensors to capture user characteristicdata; and wherein to authenticate the user via a plurality ofauthentication factors includes to authenticate the user as a functionof the user characteristic data captured by the one or more sensors.

Example 48 includes the subject matter of any of Examples 39-47, andwherein the plurality of instructions further cause the computing deviceto (i) monitor a presence of the user relative to the computing device;(ii) generate a continuous presence assertion to indicate thatcontinuous presence of the user relative to the computing device ismonitored; (iii) send the continuous presence assertion to the keydistribution center server; (iv) determine whether the user is presentrelative to the computing device; and (v) notify the service providerserver of a loss of the continuous presence of the user relative to thecomputing device in response to a determination that the user is notpresent relative to the computing device.

Example 49 includes the subject matter of any of Examples 39-48, andwherein to notify the service provider server of a loss of thecontinuous presence of the user relative to the computing deviceincludes to send a notification message to the service provider serverto inform of the loss of the continuous presence of the user relative tothe computing device.

Example 50 includes the subject matter of any of Examples 39-49, andwherein the notification message includes a Kerberos message.

Example 51 includes the subject matter of any of Examples 39-50, andwhere the Kerberos message includes a Kerberos safe message.

Example 52 includes the subject matter of any of Examples 39-51, andwherein the plurality of instructions further cause the computing deviceto send a Kerberos safe message to the service provider server at areference interval.

Example 53 includes the subject matter of any of Examples 39-52, andwherein the plurality of instructions further cause the computing deviceto (i) generate a user key pair on behalf of the user, wherein the userkey pair includes a user public key and a user private key generated onbehalf of the user; (ii) provide the user public key to the keydistribution center server via a secure key exchange; and (iii) sign thecontinuous authentication assertion with the user private key prior tothe continuous authentication assertion being sent to the keydistribution center server; wherein to send the continuousauthentication assertion to the key distribution center server includesto send the signed continuous authentication assertion to the keydistribution center server; and wherein the service ticket received fromthe key distribution center server includes the signed continuousauthentication assertion and the user public key.

Example 54 includes the subject matter of any of Examples 39-53, andwherein to provide the user public key to the key distribution centerserver via a secure key exchange includes to provide the user public keyto the key distribution center server via a SIGn-and-MAc session.

Example 55 includes the subject matter of any of Examples 39-54, andwherein the service ticket received from the key distribution centerserver further includes a privilege attribute document, the privilegeattribute document includes one or more policies required to access theservice provider server.

Example 56 includes the subject matter of any of Examples 39-55, andwherein to request an initial ticket from the key distribution centerserver includes to request a ticket granting ticket from the keydistribution center server; and wherein to receive the initial ticketfrom the key distribution center server includes to receive the ticketgranting ticket from the key distribution center server.

Example 57 includes the subject matter of any of Examples 39-56, andwherein the continuous authentication assertion includes at least one ofa Kerberos safe message or a security assertion markup language message.

While the present invention has been described with respect to a limitednumber of embodiments, those skilled in the art will appreciate numerousmodifications and variations therefrom. It is intended that the appendedclaims cover all such modifications and variations as fall within thetrue spirit and scope of this present invention.

What is claimed is:
 1. A computing device to continuously authenticate auser via multiple authentication factors, the computing devicecomprising: a trusted execution environment module to: generate acontinuous authentication assertion to indicate that continuousauthentication of a user is monitored; send the continuousauthentication assertion to a key distribution center server; request aninitial ticket from the key distribution center server; receive theinitial ticket from the key distribution center server; request aservice ticket from the key distribution center server required toaccess a service provider server; receive the service ticket from thekey distribution center server required to access the service providerserver, wherein the service ticket comprises the continuousauthentication assertion; request access to the service provider serverwith the service ticket; and access the service provider server inresponse to verification of the continuous authentication assertion.